BASIC Wars
Volume Number: 2
Issue Number: 8
Column Tag: Basic School
BASIC Wars - A First Look 
By Dave Kelly, Editorial Board
They've arrived! It's been a long wait but they're here. The Macintosh now has
several new BASIC development tools to work with. I hope to bring you some kind of
quick overview of the features (both good and bad) of these new products:
Z Basic™ (version 3.01) Zedcor
True BASIC™ (version 1.1) True Basic Inc.
PCMacBASIC (version 1.60) Pterodactyl
I'll also try to bring you a re-run in the way of comparison of Softworks BASIC
and MS BASIC. Believe me, it's still not easy to pick any one version as my favorite.
They all have their pluses and their minuses. I hope to present an accurate view of
each. Please keep in mind that the vendors are working hard to correct last minute bugs
or deficiencies and that a follow-up article will report on how successful these efforts
have been.
Before we get into any of the features, here is the first benchmark that we use
for our comparison. This is the same benchmark that was presented in the May 1986
MacTutor.
Accuracy Benchmark
(See Table 1)
40 time1=TIMER :REM Use TIME for Softworks Basic
50 s=0
100 x=0
200 FOR n=1 TO 1000
300 s=s+x*x
400 x=x+.00123
500 NEXT n
600 PRINT s,x
700 time2=TIMER
800 Totaltime=time2-time1
900 PRINT "Elapsed Time =",Totaltime,"Seconds.
This same benchmark has been run on various desk top computers to compare
their speed and accuracy in engineering or scientific applications. Most desk top
computers convert real numbers to their binary equivalent before performing
software math operations. This introduces an error depending on the precision of the
math routines that can propagate through many math operations, producing a
considerable error in the final result. This benchmark program, developed by R.
Broucke at the University of Texas, Austin, tests for this error propagation. See Table 1
for the results on different computers.
Accuracy in these computers is a function of the number of bytes used to
represent the mantissa. A three byte mantissa is used in most versions of Microsoft
BASIC (single precision). This is illustrated by the systems that give 503.545 for an
answer. The TRS-80, Altair 8800, Osborne MBASIC and IBM personal computer are
typical of this version of Microsoft BASIC. Those versions of Microsoft BASIC
implemented on a 6502 microprocessor typically use a four-byte mantissa, giving
503.543832 or something similar as the answer. Note that only those computers NOT
using a Microsoft version of BASIC come up with the right answer (with the exception
of the decimal version of Macintosh MS BASIC). The HP 9836 uses 6.5 bytes or 52
bits to represent the mantissa, and 11 bits to represent a 3 digit exponent! This is why
the HP 9836 has such a high precision compared to the other desk top computers.
The speed of each computer is related to the efficiency of it's BASIC interpreter
and the clock speed of the computer. Most of the 6502 based systems run at 1 mHz,
while the Z-80 systems typically run between 2 and 4 mHz. The reason there is not
more of a difference between the running speeds of the 6502 and the Z-80 is because
the 6502 is very efficient in addressing memory, and hence the BASIC interpreters on
the 6502 machines are much more efficient than the Z-80 based interpreters. This
difference is particularly true for the APPLE II versus the TRS-80 model II, which
runs at more than twice the clock speed of the APPLE, yet is nearly identical in the
accuracy bench mark speed. The Macintosh runs at 7.8336 mHz, one of the fastest on
the list. The difference between an interpreter and a compiler is shown by the fact that
the HP 9836 PASCAL runs twice as fast as the HP 9836 BASIC for this bench mark.
This is also evident from the comparison of compiled Basics and interpreted Basics on
the Macintosh.
Remember that any benchmark test only checks specific attributes of the
language. Other areas may have strengths or weaknesses which the benchmark cannot
address. Of the Macintosh Basics available, it appears that True BASIC is fastest of those
languages giving the correct answer, with Z Basic, PCMacBASIC and MS Basic (d) being
the only other Basics to give a correct answer. True Basic's math routines are
impressive in accuracy, speed, and breadth.
The Sieve of Erastothenes benchmark results shown in TABLE 2 indicate that Z
Basic overall is the fastest BASIC available. That is reasonable since Z Basic is
compiled. True Basic has very good results for being an interpreted language. One
glaring result is the PCMacBASIC time on the Sieve is 66 seconds, significantly slower
than Z Basic. The reason for the apparent slow time is that PCMacBASIC uses dynamic
arrays, which can be re-dimensioned and even spooled to disk as virtual arrays. The
extra overhead of keeping track of the dynamic array size when addressing elements in
the array is magnified by this benchmark and accounts for the time difference between
it and Z Basic, which uses standard fixed arrays. This is a powerful feature, but one
that has a trade-off in execution time when a lot of array addressing is involved as in
the Seive.
Sieve Benchmark
(See Table 2)
DEFINT a-s
10 DIM FLAGS(8191)
20 PRINT "10 iterations
22 T=TIMER
30 FOR M = 1 TO 10
40 COUNT = 0
50 FOR i = 1 TO 8191
60 FLAGS(i) = 1
70 NEXT i
80 FOR i = 1 TO 8191
90 IF FLAGS(i) = 0 GOTO 170
100 PRIME = i + i + 3
105 REM PRINT PRIME
110 K = i + PRIME
120 IF K <= 8190 THEN
FLAGS(K) = 0:K = K + PRIME:GOTO 120
160 COUNT = COUNT + 1
170 NEXT i
180 NEXT M
181 T2=TIMER
190 PRINT COUNT;"primes";T2-T;"Sec.
200 FOR i=1 TO 10:BEEP:NEXT i:END
The Basics Compared
The decision of which version of BASIC is the best is a tough one. I've tried to
determine which attributes I would like to see most. For the Macintosh there are also
some considerations that don't apply to the average computer. (After all that's why the
Mac isn't your average computer!) A few of the attributes that I feel are important are
(not necessarily in this order):
1. Support of the Macintosh Standard User Interface including proper
implementation of Menus, Windows, Controls, etc.
2. Compatibility with HFS.
3. Access to the Macintosh Toolbox routines.
4. Ease of use. (Editing, documentation, etc.)
5. Speed
6. Reliability (How much does it BOMB?)
7. Price
Of a lesser importance is: Compatibility with versions of Basic on other
computers. In most cases the major impact of this is to help sales of BASIC. Most
Macintosh programmers (99% of them) want to write toolbox programs, which by
their very nature, will not be compatible with other computers anyway. The only
place where compatibility counts is when it helps make programming easier because
the BASIC commands are similar, such as compatibility with MS Basic on the Mac.
Both Z Basic and True Basic have taken great pains to present a family of
compatible Basics for different machines. Z Basic is available on several other
computers including Apple //, MS-DOS based systems, and Z-80 based systems. True
BASIC on the Mac is compatible with True BASIC on the IBM and the Amiga. Z Basic
appears to have done the best job of not crippling the Mac version for the sake of this
compatibility. Toolbox support is available both by direct calls to the toolbox and by
Basic statements similar to MS Basic which greatly simplify the coding of the Mac
interface. True Basic, on the other hand, requires a greater separation between it's
normal environment, which it tries to keep compatible to versions on other machines,
and the Mac interface. This separation means more work on the programmer's part to
implement a true Mac like program, since everything must be done at the toolbox level
of detail. Of the two, Z Basic is the most compatible with MS Basic on the Mac and in
fact, is the closest to being an MS Basic compiler. But True Basic is very compatible in
syntax with HP 9836 Basic and includes a very fine set of matrix commands no other
Basic outside of HP has.
PCMacBASIC, as the name implies is compatible with IBM PC BasicA and
programs written for the IBM can be easily ported over to PCMacBASIC and run on the
Mac. Again, the Mac interface access is not crippled by this compatibility, as complete
toolbox access is provided for, both as Basic commands and direct toolbox calls. This
feature might be important if there are IBM PC programs you wish to port over to the
Mac, that were done in BasicA.
Compatibility is really a secondary issue. Most of us only have one kind of
computer anyway. Even if a ported program did run, it wouldn't follow any Macintosh
standards which means they would have to be modified, and toolbox calls added to make
them "Mac-like". Why bother? It would be much better to design the program from
the ground up for the Mac in the first place, in which case, you wouldn't care that your
code was compatible with XYZ's computer.
The use of the Macintosh standard interface is an attribute that is a must for any
language. Show me a program that supports the Standard User Interface and I'll show
you one that is easy to learn to use. It's the Macintosh way! UNFORTUNATELY, there
are some programmers out there that don't follow it very well. We've all seen the
results of this when HFS was released. Those programs that don't conform to the
standard have had to be modified to work with HFS (i.e. software updates). Some of the
programs still exist without modifications, indicating to me that the programmers just
don't care if it follows the standard or not. Well, I care! In fact, one of my first
questions that I ask before buying any new software is "Is it HFS compatible?", and
"Does it follow the Mac Standard User Interface?". That's dangerous though, because
some of the incompatibility is subjective. For example, MS Basic is useable with HFS,
but depending on the program, you may have to have things located on the root
directory. (Take heed Microsoft, MS BASIC is NOT 100% HFS compatible.) Some
software packages claim to be compatible with HFS when in fact this only means that it
can be made to work around HFS. As it turns out, some files (usually support files, help
files or similar type files) must be on the root volume or in the same folder as the
application. I'm not so sure if this can really be called HFS compatibility or not.
HFS compatibility should mean a program can find it's own working files no
matter where the user chooses to put them! We have already published an HFS Lost File
Finder DA. A similar tree search subroutine can be added to any application to search
the directories for it's working files. Developers simply have been too lazy to
implement this properly. At the very least, a simple standard file dialog box can be
called up to ask the user where he put the needed intermediate file. Recently some
programs have been taking this approach (Spellswell for its dictionary file) and we
think this is much better than artificially confining the needed file to a certain folder
or disk.
All the versions of BASIC claim to work with HFS. PCMacBASIC needs certain
.REL files (included in a runtime folder) to be on the same disk as the object being
compiled, and in the same folder as the user's compiled object file, which is not what
you would expect. A dialog box is presented which allows the user to select through the
standard file dialog, where his source, resource, listing and object files are located.
This works nicely, but having to place the system's ".REL" files in the folder with the
user's object file is unwieldy. The reason it was done this way was to get around HFS
incompatibilities with the MDS and McAssembly assemblers and linkers. The
McAssembly assembler and linker are built into PCMacBASIC, which assembles and
links the Basic source into a stand alone application. So HFS problems strike home in
round about ways. This Basic also provides HFS commands for your programs so they
can create and access folders correctly. None of the other Basics yet consider the HFS
compatibility requirements of the user's programs.
The Basics that require the use of the MDS editor already have some problems
because the MDS editor itself is not yet HFS compatible. There are other commercial
editors available which will work just fine, such as QUED. These HFS incompatibilities
are not fatal to the use of the products involved. We can suffer with it till updates are
provided. Z Basic has some problems with HFS in the command mode which Zedcor tells
me they are working on fixing for the next release. Otherwise, during program
execution there doesn't seem to be a problem. We have already reported on how MS
Basic must be in the same folder as it's library files and source program.
Mac User Interface
When the implementation of menus, windows and controls etc. in each of the
BASIC versions are compared, differences become apparent. All of the versions
reviewed seem to make use of menus. Menus should give access to desk accessories and
at least have the File and Edit menus as standard. Controls that are in windows should
work. That is, if there is a go-away box, size box, buttons, and/or scroll bars, they
should work. Although you can define your own windows with Z Basic, the default
window (appears when no window has been opened) has a go-away and size box that
won't work unless your program is checking for it. Because Z Basic is compiled, there
is some responsibility for the programmer to see that the functions all work. Most of
the time the default window is used for quick programs that you don't want to spent a lot